| From: | David McMinn |
| Date: | 24 Sep 2001 at 20:14:38 |
| Subject: | RE: Debugger & Messageports |
>===== Original Message From Thilo Köhler <koehlerthilo@gmx.de> =====
>If I set up a messageport with OS functions
>the debugger can`t break the running programm
>anymore if at least one message was sent.
I've never seen that. The only time the debugger cannot break the program is
if you have called the Wait_ (or WaitPort_) command from your program - the
debugger must wait until your program is sent a message so it is not waiting.
>Maybe some signal flags are used by the Debugger
>which are overwritten by creating a messageport.
The debugger runs as a separate program, and doesn't use any signals (IIRC the
debugger works using exceptions I think - your program has lots of TRAP
instructions in it).
>BTW: How to find out the right processor-type in OS friendly
>way ? (inlcuding the 68060)
>The "processor" command gives no 68060 and is maybe
>not OS friendly (or not suitable for the future CPU`s).
The proper way to do it is examine the execbase AttnFlags field, which is
probably what the Processor command does. I don't think there is an easy way
to be future-proof. For example, the PPC CPU is stored somewhere else
(ppc.library or powerpc.library IIRC). You could examine the (currently)
unused bits in the AttnFlags field, but that probably will not work as you
would need to guess what future CPUs they would put there.
I guess you could use a library such as identify.library, as then when new
CPUs are available only the identify library needs to be updated and not your
code (and there's more chance of that happening than BB2 being updated ;).
---------------------------------------------------------------------
To unsubscribe, e-mail: blitz-list-unsubscribe@netsoc.ucd.ie
For additional commands, e-mail: blitz-list-help@netsoc.ucd.ie